System and Method for Location-Based Transactions

ABSTRACT

A system and method for using at least location information to facilitate a transaction is provided. In one embodiment of the present invention, a mobile application operating on a mobile device is used to determine a location of the mobile device. Location information is then provided to a host device, where it is used to identify a merchant. Information is also entered (or acquired) to identify a shopping cart that is used during a shopping session. As items are placed within the cart, information concerning the items is presented to the user via a display on the cart and/or the mobile device. The first party can then interact with the same to enhance their shopping experience (e.g., access coupons, search for items, etc.). Once the user is done, the host device will charge a payment method linked to the user&#39;s account for items that are in the shopping cart.

BACKGROUND OF THE INVENTION 1. Field of the Invention

The present invention relates to use of location information, along withother data, to carry out a transaction, and more particularly to anapplication operating on a mobile device (e.g., smartwatch, smartphone,etc.), the application being configured to acquire a location of themobile device and to use the acquired location, along with other data(e.g., user name, password, biometric data, time, etc.), to identify astore and a shopping cart at the store, both the shopping cart and themobile device being used by the user to perform a transaction (e.g.,shop for an item, purchase an item, etc.).

2. Description of Related Art

Mobile devices, such as smartphones and smartwatches, are becoming moreand more a part of our everyday lives. For years, there has been talk ofa “digital wallet,” where a person's mobile device replaces theirwallet, and can be used to pay for goods and services. Over the pastseveral years, this talk has become a reality with services such asApple Pay™. Apple Pay™ uses near field communication (NFC) technology tofacilitate a transaction between a person's smartphone and a merchant'spoint-of-sale (POS) device. However, as shown in FIG. 1, in order forthis transaction to take place, both the smartphone 300 and the POSdevice 400 must include NFC circuitry (e.g., 302, 402). NFC is a set ofcommunication protocols that enable two electronic devices in closeproximity (i.e., within four centimeters) to communicate with eachother. The NFC standard is based on existing radio-frequencyidentification (RFID) standards and involves electromagnetic inductionbetween two loop antennas.

While NFC technology can be used to facilitate a transaction, it hasseveral drawbacks. First, NFC circuitry must be included in the mobiledevice, such as the smart phone or the smartwatch. Not only does suchcircuitry require a certain amount of real estate, but it adds costs tothe mobile device; costs that are ultimately born by the consumer.Second, NFC circuitry must also be included in the POS device (e.g., thecash register). Again, not only does such circuitry require a certainamount of real estate, but it adds costs to the POS device; costs thatare ultimately passed on to the consumer. And finally, the two devicesmust be in close proximity (less than four centimeters) in order tofunction properly.

In an effort to address some of these drawback, Samsung™ launchedSamsung Pay™. While Samsung Pay™ supports NFC technology, it alsosupports Magnetic Secure Transmission (MST) technology. MST technologyis technology that emits a magnetic signal that mimics the magneticstrip on a traditional payment card. As shown in FIG. 2, MST circuitry302′ in the smartphone 300′ sends a magnetic signal to the card reader402′ of the POS device 400′, emulating the swiping of a physical card.While MST technology has advantages over NFC technology (e.g., it canfunction with traditional POS devices, which include traditional cardreaders), it still requires MST circuitry 302′ to be included in thesmartphone 300′, increasing the smartphone size and cost, and requiresclose proximity to the card reader in order to function properly. Thisis extremely problematic with portable electronic devices becomingsmaller and smaller.

For example, smartwatches are becoming more and more popular, and moreand more advanced. With a smartwatch, however, real estate is extremelylimited, and there simply is not room for NFC and MST technology. And tothe extent such technology could be added, it would be to the detrimentof (e.g., in place of) other technology (e.g., technology that wouldallow the smartwatch to function autonomously, or without use of asmartphone). Furthermore, smartwatches also have a limited display, orare limited in the amount of information that can be provided to theuser.

Thus, it would be advantageous to develop a mobile solution thatovercame as least some of the foregoing drawbacks. For example, it wouldbe beneficial if a small mobile device, such as a smartwatch, couldfacilitate a transaction without requiring any additional hardwareand/or without having to be in close proximity to (or, in certainembodiments, even requiring) a POS device. It would also be advantageousto use a second, preferably larger, display on a second device (e.g.,ATM, shopping cart, etc.) to display information to the user that maynot be easily displayed on the mobile device or may more conveniently bedisplayed on the second device.

SUMMARY OF THE INVENTION

The present invention provides a system and method for using at leastlocation information to facilitate a transaction. Preferred embodimentsof the present invention include a host device in communication with atleast a mobile device (e.g., smartphone, smartwatch, tablet, etc.) via awide area network (WAN), such as the Internet.

In one embodiment of the present invention, the mobile device downloadsa mobile application (e.g., from the host device, a third party, etc.).The mobile application can then be opened and/or logged into by a firstparty (e.g., a user of the mobile device). Information provided by themobile application (e.g., user name, password, etc.) can then be used toidentify an account, which is preferably linked to at least one paymentmethod (e.g., user's credit card, user's debit card, user's PayPal™account, user's host account, etc.). The application then provides thehost device with other information, such as biometric data on the user,location information (e.g., the mobile device's location, informationthat can be used to determine the mobile device's location, etc.), time,etc., which can be used to authenticate the user (e.g., determinewhether the user is authorized to use (or is associated with) theidentified account) and identify a second party (e.g., a particularmerchant). The latter may be accomplished using a second party/locationmap stored in a database on the host device, where location informationprovided to the host is used to identify (e.g., lookup) a second partyin the database.

Once the second party is located, information concerning the firstand/or second party can then be provided to the first party via themobile device, an intermediate device (e.g., a device that allows themobile device to communicate with the host device), and/or a separate,network-enabled device (e.g., a device owned and/or operated by thesecond party). Information on the second party, which may be previouslyprovided by the merchant (e.g., a merchant device), stored in thedatabase on the host device, and linked (directly or indirectly) to thelocation information, may include the identity of the second party(e.g., merchant's name, address, phone number, logo, store hours, etc.),and/or goods/services provided by the second party (e.g., a menu ofgoods/services provided by the merchant, a particular good/servicepurchased by the first party, etc.). Information on the first party mayinclude the identity of the first party (e.g., name, email address,phone number, linked payment method, etc.) and/or goods/servicesselected (directly or indirectly) by the first party (e.g., directly viathe mobile application, or indirectly via an employee or agent of thesecond party).

The host device may then continue to communicate with the mobile device,the merchant device, any intermediate device, a third-party financialdevice, and/or any separate, network-enabled device until thetransaction is completed. This further communication may involve thedisplay of options (or sub-options) to the first party (e.g., via themobile device, an intermediate device, and/or a separate,network-enabled device), the selection of at least one option (orsub-option) by the first party, the providing of authenticating data(e.g., a PIN, etc.) by the first party, authenticating theauthentication data (e.g., determining whether the provided PIN matchesa previously provided PIN, determining whether a provided Card SecurityCode (CSC) matches the numbers on the back of a credit or debit card,etc.), which may be performed by the host device, the merchant device,and/or the financial device, determining whether the transaction isbeing made within an acceptable window of time (e.g., during businesshours, during a time period allotted by the second party for the firstparty, etc.), transferring funds to complete the transaction (e.g., fromthe identified account to the merchant, etc.), and/or providingconfirmation of the transaction (e.g., to the mobile device, themerchant device, the separate, network-enabled device, etc.), which maytake place either before or after the actual funds have beentransferred.

By way of example, a user may walk into (or up to) a store or kiosk andopen and/or log into the mobile application. The host device may thenuse the login information to locate the user's account in the database,which may be linked to at least one payment method. The mobileapplication may then provide location information to the host device,where it is used to identify the store/kiosk. Information concerning thestore/kiosk (e.g., name, logo, etc.) may then be provided to the mobileapplication and displayed to the user. This allows the user to confirmthat the correct store has been located. The host device may thenprovide the user with a menu of goods/services offered at thestore/kiosk. This can be done via the mobile device, an intermediatedevice, and/or a separate, network-enabled device (e.g., a device ownedand/or operated by the second party). The user can then interact withthe mobile device to select at least one good/service. After theselection has been made and/or acknowledged by the user, the host devicemay provide the transaction (or acknowledgement) to the merchant device,charge the user's payment method (if needed), and provide a receipt tothe mobile application operating on the mobile device and/or themerchant device, which may include a separate, network-enabled device(e.g., Point-of-Sale (POS), Automated Payment System (APS), AutomatedTeller Machine (ATM), Set Top Box (STB), gaming device, etc.).

If the transaction is a purchase, the user can use the receipt toacquire the good/service from the store/kiosk and/or show proof ofpurchase before leaving the store/kiosk. As mentioned above, such amethod may require a determination of whether the transaction is beingperformed during an acceptable window of time (e.g., during businesshours, etc.). It may also require the user (including the mobile device)to be at a particular location in order for the transaction to beprocessed. In other words, location information can be used to bothidentify a particular merchant (e.g., allowing the host to provide theuser with information on the merchant, such as store name, hours ofoperation, available goods/services provided by the merchant, etc.) andto authenticate the user (e.g., requiring the user to be inside oradjacent the merchant's store/kiosk before the user can purchasegoods/services from the merchant, etc.).

In another example, the host device may receive an order from themerchant device (e.g., an order that the user placed with a cashierwhile in the store, etc.). The location information provided by themobile application is then used to not only identify the store/kiosk buta pending order. In this example, the pending order is provided to themobile application. If the user acknowledges the order, then the user'spayment method is charged, and receipts are provided to the mobileapplication operating on the mobile device and the merchant device. Thereceipt would inform the merchant that the user has paid for the pendingorder. In this embodiment, it may not be necessary to determine whetherthe transaction is being performed during an acceptable window of time,as the second party's employee or agent (e.g., cashier, etc.) isinvolved in the transaction, ensuring that the transaction is takingplace during an appropriate time (e.g., during business hours, etc.). Asbefore, the location information can also function to authenticate theuser, requiring the user to be at a particular location in order for thetransaction to be processed. Such a feature would ensure that the mobiledevice is not being used to process a transaction from a remote (orunauthorized) location.

In yet another example, if there is more than one order pending, thehost device could either provide the mobile application with the pendingorders, requiring the user to select the order that is theirs, oranother method could be used to associate one of the pending orders tothe mobile application (or user's account). For example, the merchantcould enter a name (or other identifying information) that could be usedto identify the proper account, the user could enter identifyinginformation (e.g., order number, etc.) that could be used to identifythe proper order, or individual locations within the store could be usedto identify individual orders. For example, a location in front of afirst cashier could be used to link an account of a user standing atthat location to an order placed by the first cashier, etc.

In embodiments of the present invention, the mobile device may includeat least one transceiver configured to communicate with the host devicevia the Internet (e.g., either directly or indirectly, e.g., via anintermediate device) and to communicate with other devices in order toacquire location information and/or determine a user's location. Forexample, the transceiver(s) may be configured to communicate with thehost device (either directly or indirectly) via at least one satellite,at least one cell tower, and/or at least one wireless (Internet) device(e.g., using Bluetooth, WiFi, etc.). The transceiver(s) may also beconfigured to communicate with these devices to acquire locationinformation (e.g., using GPS, GSM (e.g., multilateration of radiosignals between cell towers), WiFi-based positioning, etc.). In analternate embodiment of the present invention, location information isprovided by at least one radio head in a distributed system, asdescribed in the co-pending patent application (Ser. No. 15/154,970),which is incorporated herein by reference.

A critical aspect of the invention is determining the location of theuser, or more particularly the user's mobile device. As discussed above,this may be the actual location of the device, a more general locationof the device, or a location of an intermediate device. This informationcan be used to authenticate the user and/or to identify at least oneother party (e.g., a merchant). In one embodiment of the presentinvention, with respect to the latter, the system only needs to identifyone from a plurality of parties (e.g., a plurality of stores, etc.). Forexample, if the device is located in (or in front of) a firststore/kiosk, then acts of commerce associated with the first store/kioskcan be provided to the user. Similarly, if the device is located in (orin front of) a second store/kiosk, then acts of commerce associated withthe second store/kiosk can be provided to that user.

In another embodiment of the present invention, location of the deviceis used to determine more than just the store in which the device islocated. In this embodiment it is further used to identify where insidethe store the device is located. For example, the device could be infront of a first checkout, a second checkout, etc. This embodimentallows multiple pending orders to be linked to the proper user, ormobile application. For example, if the user is standing in front of thefirst cashier, and the first cashier has just entered an order, then theorder can be associated with the user regardless of other orders enteredby other cashiers, or other applications operating on other mobiledevices within the store.

As discussed above, location information can also be used toauthenticate the user. For example, if the user is attempting to performan ATM transaction, the present invention can use location informationto ensure that the user (including the mobile device) is located near(or in front of) the ATM. Similarly, if the user is attempting toperform a store transaction, the present invention can use locationinformation to ensure that the user is located within (or in closeproximity to) the store. Not only would this prevent a user fromperforming a transaction from remote (or unauthorized) locations, but itwould allow other security measures, such as security cameras at theauthorized location(s), to discourage fraudulent usage.

As discussed above, a second party/location map may be used (along withlocation information of the mobile device) to identify a particularsecond party. In one embodiment, this data is also used to authenticatethe user. In other embodiments, other data is further (or alternatively)used to authenticate the user. For example, a particular location (e.g.,X-Y coordinates) along with a first proximity (e.g., within aone-hundred-foot radius of the particular location) may be used toidentify a second party. In one embodiment, this same data is used toidentify authorized locations, or authenticate the user. In otherembodiments, other data, perhaps more stringent data (e.g., within a10-foot radius of the particular location, within a 10-foot radius froma different location, etc.), is used to identify authorized locations,or authenticate the user. As such, the second party/location map mayinclude several fields, including information on the second party (e.g.,name, address, phone number, hours of operation, goods/servicesprovided, etc.), information that can be used to identify the secondparty (e.g., at least one location, a first proximity value, etc.),and/or information that can be used to identify authorized locations(e.g., at least one location, a second proximity value, etc.).

The user's account may also be linked to at least one authorizedlocation (e.g., at least one location, proximity data, etc.). This couldbe used, for example, to authenticate the user if the user is attemptingto carry out a transaction from a remote location (e.g., from the user'shome, etc.). This could also be used in delivering an item to anauthorized location. For example, a delivery person (e.g., UPS, FedEx,Amazon Prime, etc.) may use the mobile device (or an applicationoperating thereon) to provide location information (i.e., a location ofthe mobile device) to the host device. If it is determined that thedelivery person is at or near the authorized location, then the hostdevice provides instruction to a network-enabled device (e.g., operatedby the first party, etc.), instructing the device to unlock or provideaccess to a particular building or a particular secured enclosure. Oncethe item is placed inside, the building or enclosure can again besecured (e.g., locked).

In certain embodiments of the present invention, the mobile device is asmartphone. However, in other embodiments, the mobile device may be awearable device, such as a smartwatch. In such embodiments, because theamount of information that can be displayed is limited (e.g., due to thesize of the wearable device), the mobile application and/or host devicemay be configured to display data to the first party using a pluralityof display devices, or display means. For example, in one embodiment ofthe present invention, the wearable device may be configured to displayfirst content on the mobile device and second content elsewhere. Forexample, the second content could be projected by the mobile device(e.g., using a projection device). By way of another example, the secondcontent could be displayed using a separate, network-enabled device. Forexample, if a wearable device (e.g., a smartwatch) is in communicationwith the host device via an intermediate device (e.g., a smartphone),then second content may be displayed on the intermediate device (or adisplay portion thereof).

In another example, second content may be displayed on a network-enableddevice owned and/or operated by the second party (or a display portionthereof). By way of example, a first party standing in front of an ATMmay open and log into the mobile application. Using the location of thewearable device, the mobile application (or host device) may identifythe ATM, and ask the first party (via the wearable device) to confirmwhether they would like to use the application to facilitate atransaction with the ATM. If the first party answers in the affirmative,the host device may then ask the first party (e.g., via the ATM display)to enter their PIN. The first party may then enter their PIN on thewearable device. If the provided PIN matches a predefined PIN, then thehost device may provide the first party with a plurality of options,such as withdraw money, make a transfer, etc. The options can either beprovide on the wearable device or provided on the ATM. However, if theoptions are provided on the ATM, the options should correspond toentries on the wearable device (e.g., press “1” for withdraw, “2” fortransfer, etc.). By selecting the appropriate option, which may resultin further sub-options (e.g., enter the amount to withdraw, etc.), themobile application, along with the ATM, can be used to facilitate afinancial transaction.

The same technology could be used to interact with other network-enableddevices. For example, if the first party is seated in front of a gamingdevice (e.g., slot machine, video poker, keno, lottery, etc.), themobile application could be used to add money to the gaming device,retrieve money from the gaming device, and/or play the gaming device. Ifa financial transaction is requested, then the sequence of steps may besimilar those use with the ATM. If, however, the wearable device is usedto play the game, the gaming device may be used to display options, andthe wearable device may be used to select from corresponding entries(e.g., press “1” for slots, “2” for video poker, etc.). By way ofanother example, if the first party is in a hotel room or on anairplane, the mobile application could be used to interact with atelevision or a related STB to select a movie to be played (e.g., theTV/STB could be configured to display a plurality of movie options, andthe wearable device could be configured to provide the user with aplurality of corresponding entries (e.g., press “1” for the first movie,“2” for the second movie, etc.)).

While wearable devices may have drawback (e.g., screen size, etc.), theyalso include certain advantages. For example, because the wearabledevice is being worn by the first party, it could be used to capturebiometric data of the first party. For example, a camera feature on thedevice could be used along with facial and/or retina recognitionsoftware to identify/verify the first party, a microphone feature on thedevice could be used along with voice recognition software toidentify/verify the first party, and/or a sensor feature on the device(e.g., capturing heart rate data, etc.) could be used to confirm thatthe wearable device is being worn while the mobile application is beingused to facilitate a transaction. By way of another example, the mobileapplication may use the sensor data (e.g., EKG, etc.), either alone ortogether with other data, to uniquely identify the first party. By beingable to confirm that the user has possession of the mobile device, is ata location of the transaction, knows the correct password, and exhibitscorrect (or matching) biometric data, the mobile application, along withthe host device, can be used to carry out sensitive transactions, suchas banking or other financial transactions. If the mobile deviceincludes a camera, the camera could further be used to capture a photoof the user while the transaction is being carried out. The photo couldthen be provided to the host and stored together with transactioninformation. Such use of the mobile device (e.g., as a security camera)should further detour fraudulent usage of the present invention.

The present invention may also be used in conjunction with a shoppingcart or basket to enhance a first party's shopping experience. Forexample, a host device may be in communication with a plurality ofdevices either directly or indirectly, including a mobile deviceoperated by a first party, a merchant device operated by a second party,and a shopping cart, which may or may not be operated by the secondparty. The shopping cart (or basket) may include intelligence, such as aprocessor, memory, transceiver(s), scanner, display, and input device,where the scanner (either alone or together with other technology) isconfigured to identify items that have been placed into the cart (orbasket), and the display and input device are configured, respectively,to provide information to the first party and to receive informationfrom the first party.

In one embodiment of the present invention, each cart (or basket) hasits own unique identifier (ID), allowing the system to identify aspecific one (from a plurality) that is being used by the first party.This may be accomplished, for example, by entering a unique ID of thecart/basket into the mobile device (e.g., an ID printed on thecart/basket or provided on a display portion thereof). Once the devices(mobile device, merchant device, host device, shopping cart or basket)are linked, the first party can use the mobile device and/or theshopping cart (or the display and/or input device portions thereof) toparticipate in a shopping session.

For example, the first party may be presented (on the shopping cartand/or mobile device) with a plurality of options, including a mapbutton, a search button, and a coupon button. If the map button isselected, a map of the store may be presented on the shopping cartdisplay. If the search button is selected, the first party may bepresented with a field for entering at least one search term (e.g.,“mashed potatoes”). Search results, which may include a map showingwhere the item is located, may be provided on the shopping cart display.The shopping cart display can also be used to provide the first partywith coupons (generic or personalized), information concerning priorpurchases (e.g., information stored by the merchant and/or host devicesfrom prior sessions), or information concerning a shopping list (e.g.,information uploaded by the first party).

A more complete understanding of a system and method for using at leastlocation information to facilitate a transaction will be afforded tothose skilled in the art, as well as a realization of additionaladvantages and objects thereof, by a consideration of the followingdetailed description of the preferred embodiment. Reference will be madeto the appended sheets of drawings, which will first be describedbriefly.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a prior art mobile device communicating with a POS deviceusing Near Field Communication (NFC) technology;

FIG. 2 depicts a prior art mobile device communicating with a POS deviceusing Magnetic Secure Transmission (MST) technology;

FIG. 3 depicts a system that uses at least location information tofacilitate a transaction in accordance with one embodiment of thepresent invention, said system comprising at least a host device incommunication with a mobile device, a merchant device, and/or athird-party device (e.g., payment device);

FIG. 4 depicts one embodiment of components included in the mobiledevice shown in FIG. 3;

FIG. 5 depicts exemplary devices that the mobile device may communicatewith in order to acquire location information;

FIG. 6 depicts another device (i.e., radio head) that the mobile devicemay communicate with in order to acquire location information;

FIG. 7 illustrates how a plurality of radio heads can be used toidentify the mobile device's location (e.g., x, y, and/or z).

FIG. 8 depicts a method for using at least location information tofacilitate a transaction in accordance with one embodiment of thepresent invention;

FIG. 9 depicts a method for using a mobile application to facilitate atransaction in accordance with one embodiment of the present invention;

FIGS. 10a-f depict exemplary screen shots of a mobile application beingused to facilitate a transaction in accordance with one embodiment ofthe present invention;

FIG. 11 illustrates use of the present invention to locate a mobiledevice within one of a plurality of establishments;

FIG. 12 illustrates use of the present invention to locate a mobiledevice within an establishment;

FIG. 13 depicts an exemplary smartwatch, which can be configured tofunction in accordance with alternate embodiments of the presentinvention;

FIGS. 14a-e depict exemplary screen shots of a mobile application beingused to facilitate a transaction in accordance with alternateembodiments of the present invention;

FIGS. 15a-c depict exemplary ways of providing information to a user ofthe smartwatch in accordance with alternate embodiments of the presentinvention;

FIG. 16 depicts yet another way of providing information to a user of amobile device, such as a smartphone or a smartwatch;

FIG. 17 depicts features that may be includes on a smartwatch, and usedto facilitate a transaction, including, sensors (e.g., heartratesensors, EKG sensors, etc.), a microphone, a camera, and/or projectiontechnology;

FIGS. 18a-c depict exemplary uses for the present invention, including,but not limited to, facilitating a banking transaction, a gamblingtransaction, and/or an entertainment transaction;

FIG. 19 depicts a method for using at least location information tofacilitate a transaction in accordance with another embodiment of thepresent invention;

FIG. 20 depicts a method for using at least one mobile applicationand/or program to facilitate a transaction in accordance with anotherembodiment of the present invention;

FIG. 21 depicts an exemplary database for mapping users to userinformation, merchants to merchant information, and transactions totransaction information;

FIG. 22 depicts yet another way of providing information to a user of amobile device, such as a smartphone or a smartwatch, while the user isshopping at a brick-and-mortar business;

FIG. 23 provides a first example of a shopping cart that may be used inthe embodiment depicted in FIG. 22;

FIG. 24 provides a second example of a shopping cart that may be used inthe embodiment depicted in FIG. 22;

FIG. 25 depicts one embodiment of components that may be included in theshopping carts shown in FIGS. 23 and 24;

FIGS. 26a-j depict exemplary screen shots of a shopping cart applicationand/or a mobile application being used to facilitate a transaction inaccordance with the embodiment depicted in FIG. 22;

FIG. 27a depicts exemplary screen shots of a shopping cart applicationand a mobile application being used to facilitate a transaction inaccordance with an alternate embodiment of the present invention;

FIG. 27b provides examples of how indicators can be used to guide thefirst party through a transaction or “check out” process and notify thesecond party of whether the transaction has or has not been completed;

FIGS. 28 and 29 depict exemplary databases for mapping users to userinformation, such as recent purchases, coupons (personalized and/orgeneralized), shopping lists, etc.;

FIG. 30 depicts an embodiment of the present invention, where at leastlocation information is used to deliver an item to a location associatedwith the user (e.g., the user's house, etc.), without requiring the userto be present; and

FIG. 31 depicts an embodiment of the present invention, allowing amobile application to determine the location associated with the userand to request access to said location.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Preferred embodiments of the present invention include a host devicecommunicating with at least a mobile device (e.g., smartphone,smartwatch, tablet, etc.) via a wide area network (WAN), such as theInternet. It should be appreciated that while the present invention isdescribed in terms of facilitating a financial transaction (e.g., payingmoney in exchange for goods and/or services), the present invention isnot so limited, and can be used to carry out any type of transaction(e.g., acquire money from an Automatic Teller Machine (ATM), pay forparking at an Automated Pay Station (APS), retrieve a vehicle from aparking structure/lot (e.g., valet, car rental, etc.), play a movie/gameon a television (e.g., in a hotel room, etc.) (e.g., using a Set Top Box(STB)), add funds to (or acquire funds from) a gaming machine (e.g.,slot machine, video poker, provide money to a friend or family member,etc.), paying for items present in a shopping cart, providing access forat-home delivery, etc.).

FIGS. 1 and 2 depict prior art mobile devices that can be used tofacilitate financial transactions, with FIG. 1 using Near FieldCommunication (NFC) technology and FIG. 2 using Magnetic SecureTransmission (MST) technology. While both of these technologies can beused facilitate a financial transaction, they both have commondrawbacks. For example, both technologies require additional circuitry(and additional costs) and close proximity in order to facilitate atransaction.

The present invention addresses these drawbacks by using existingcircuitry (along with custom software) to facilitate a transaction. Inone embodiment of the present invention, as shown in FIG. 3, the mobiledevice 30 can be used to facilitate a transaction by using standardmobile device circuitry to communicate with a host device 10 over a widearea network (WAN) 20, such as the Internet. The host device may also bein communication with at least one merchant device 40, such as a POSdevice, and at least one third-party device 50, such as a device at afinancial institution (e.g., a credit card company, PayPal™, a bank,etc.).

It should be appreciated that while FIG. 3 depicts the mobile device 30as a smartphone, and the merchant device 40 and the third-party device50 as desktop computers, the present invention is not so limited. Forexample, use of any networked device (e.g., desktop computer, laptopcomputer, tablet, smartphone, smartwatch, network-enabled appliance,network-enabled POS device, network-enabled monitor, network-enabledtelevision, server, etc.), or combination thereof, by either party(customer, merchant, and/or financial institution), is within the spiritand scope of the present invention. It should also be appreciated thatthe present invention is not limited to a host device 10 that includesthe components depicted in FIG. 3. For example, a host device thatincludes fewer, additional, and/or different components is within thespirit and scope of the present invention.

In one embodiment of the present invention, as shown in FIG. 3, themobile device 30 downloads a mobile application (not shown) (e.g., fromthe host device, a third party, etc.). The mobile application, operatingon the mobile device 30, can then be opened and/or logged into, where itwill communicate with the host device 10 (e.g., via the web server 12and the WAN 20). Information provided by the mobile application andstored in the database 16 (e.g., user name, password, etc.) can then beused to identify the first party's (user's) account, which is preferablylinked to at least one payment method (e.g., user's credit cart, user'sdebit card, user's PayPal™ account, user's account on the host device,etc.). Other information, such as biometric data on the user, locationinformation (e.g., the mobile device's location, information that can beused to determine the mobile device's location, etc.), time, etc., maybe received from the mobile application and used (e.g., by theapplication 14) to authenticate the user (e.g., determine whether theuser is authorized to use (or is associated with) the identifiedaccount, determine whether the user is at an authorized location, etc.)and identify a second party (e.g., a particular merchant). The lattermay be accomplished using a second party/location map stored in thedatabase 16 (discussed below).

Once the second party is located, information concerning the secondparty can then be provided to the mobile application operating on themobile device 30 and displayed to the first party (user). Theinformation, which is preferably provided by the merchant device 40,stored in the database 16, and linked (directly or indirectly) to thelocation information, may include the identity of the second party(e.g., merchant's name, address, phone number, logo, store hours, etc.),goods/services provided by the second party (e.g., a menu ofgoods/services provided by the merchant, a particular good/servicepurchased by the first party, etc.), goods/services requested by thefirst party (e.g., a request taken by an agent/employee of the secondparty, for example, while the first party is within a brick-and-mortarlocation of the second party, etc.), and/or accessories (e.g., analternative (or secondary) display device (e.g., on a shopping cart, ona shopping basket, etc.), etc.) provided by the first party and/or usedby the second party.

The host device 10 (or application 14 operating thereon) may thencontinue to communicate with both the mobile device 30 and/or thethird-party device 50 until the financial transaction is complete, whichmay involve communications between the host device 20 and thethird-party device 50 (e.g., to debit the first party's account with athird-party financial institution). Examples and details of how theinvention may be used to facilitate a transaction will now be provided.

In one embodiment of the present invention, a user may walk into (or upto) a store or kiosk (e.g., which may include an ATM, APS, STB, etc.)and open and/or log into the mobile application. The host device 10 maythen use the login information to locate the user's account in thedatabase 16, which may be linked to at least one payment method. Themobile application may then provide location information to the hostdevice 10, where it is used to identify the store or kiosk in thedatabase 16. Information concerning the store or kiosk (e.g., name,logo, etc.) may then be provided to the mobile application and displayedto the user. This allows the user to confirm that the correct store orkiosk has been located.

In a first example, the application 14 may then provide the user with amenu of goods/services offered at the store or kiosk. The user can theninteract with the menu to place an order for at least one good/service.After the order has been placed and/or acknowledged by the user, theapplication 14 may provide the order to the merchant device 40, chargethe user's payment method (e.g., after the order has beenacknowledgement by the merchant, etc.) via the third-party device 50,and provide a receipt to the mobile application operating on the mobiledevice 30 and/or merchant device 40. The user can then use the receiptto acquire the good/service from the store or kiosk and/or show proof ofpurchase before leaving the vicinity.

In a second example, the application 14 may receive an order from themerchant device 40 (e.g., an order that the user placed with a cashierwhile in the store, outside of a kiosk, by placing items within ashopping cart, etc.). The location information provided by the mobileapplication is then used to not only identify the store or kiosk but apending order. The pending order would be provided to the mobileapplication. If the user acknowledges the order, then the user's paymentmethod would be charged (e.g., via the third-party device 50), andreceipts would be provided to the mobile application operating on themobile device 30 and the merchant device 40. The receipt would informthe merchant that the user has paid for the pending order and can nowprovide the user with the corresponding good/service.

In the second example, if there is more than one order pending, the hostdevice could either provide the mobile application with the pendingorders, requiring the user to select the order that is theirs, oranother method could be used to associate one of the pending orders tothe user's account. For example, the merchant could enter a name (orother identifying information) that could be used to identify the properaccount, the user could enter identifying information (e.g., ordernumber, etc.) that could be used to identify the proper order, orindividual locations within the store could be used to identifyindividual orders. For example, a location in front of a first cashiercould be used to link an account of a user standing at that location toan order placed by the first cashier, a location in front of a secondcashier could be used to link an account of a user standing at thatlocation to an order placed by the second cashier, etc. In yet anotherexample, a shopping cart (or identifying information thereof) could beused to link the user's account to an order for items that have beenplaced within the cart.

It should be appreciated that other information may be used inconjunction with location information to identify a particular merchantand/or pending order, or to determine whether the requestedgoods/services should be provided. For example, to identify a pendingorder, time or a time period (e.g., a fifteen second window, etc.) maybe used along with location information. In other words, an order thatwas placed within fifteen seconds of a request to pay by the mobileapplication is more likely the correct order than an order that wasplaced five minutes ago. By way of another example, certaingoods/services may only be available during a particular window of time.For example, a request to purchase a particular item from a store thatis only open from 9:00 AM to 5:00 PM may only be accepted (or processed)if the request is received at an acceptable time (i.e., between 9-5). Byway of another example, a first party (e.g., tenant, real estate agent,etc.) may only be able to unlock a network-enabled door (or a doorhaving a network-enabled lock) (e.g., to a hotel room, a house for sale,etc.) owned, controlled, or operated by a second party (e.g., hotelmanager, relator, etc.) during a particular window of time, where thewindow of time is allocated by the second party for the first party.This would allow, for example, a guest to have access to a hotel room ona day, a real estate agent to have access to a house for sale during aparticular hour, etc. The same technology could be used to allow accessto, or operate any rental, regardless of whether the rental is astructure (e.g., a hotel room, etc.), a device (e.g., a vehicle, etc.),or a service (e.g., a pay-per-view movie, etc.).

It should also be appreciated that location information may includeinformation previously acquired (e.g., before the user enters thestore). This would allow the present invention to operate when themobile device is unable to acquire location information at the time apurchase is being made/confirmed. It should further be appreciated, asdiscussed above, that the present invention is not limited tofacilitating financial transactions at a store. For example, the presentinvention could be used to acquire money from an ATM (e.g., whilestanding in front of the ATM, using the mobile device to request funds),order a movie in a hotel room (e.g., while sitting in the hotel room,using the mobile device to select the movie), add funds to (or acquirefunds from) a gaming device, such as a slot or video poker machine(e.g., while seated in front of the gaming device, using the mobiledevice to facilitate the transaction), pay for a service at an APS(e.g., while standing (or parked) in front of the APS, using the mobiledevice to pay an amount owed), provide money to a friend or familymember, pay for items present in a shopping cart, provide door orlock-box access for at-home or parcel delivery, etc.

FIG. 4 illustrates components that may be included in the mobile device,such as a display 32, processor 34, memory 36, input 38, andtransceiver(s) 50. In one embodiment of the present invention, thememory 36 may be configured to store a mobile application (e.g.,downloaded from the host device, a third party, etc.), data on the firstparty (e.g., their account and information linked thereto (e.g., username, password, biometric data, payment method, etc.), data on thesecond party (e.g., their name, address, telephone number, transactionsoffered, pending transactions, etc.), data that can be used to identifya second party based on location information (e.g., at least onelocation, proximity data, etc.), and/or at least one authorized location(e.g., for the first party, the second party, etc.). The transceiver(s)may be configured to communicate with the host device via the WAN and tocommunicate with other devices in order to acquire location informationand/or determine a user's location.

For example, as shown in FIG. 5, the transceiver(s) 50 may be configuredto communicate with the host device via at least one satellite 52, atleast one cell tower 54, and/or at least one wireless (Internet) device(e.g., using Bluetooth, WiFi, etc.). The transceiver(s) 50 may also beconfigured to communicate with these devices to acquire locationinformation (e.g., using GPS, GSM (e.g., multilateration of radiosignals between cell towers), WiFi-based positioning, etc.). It shouldbe appreciated that the term location information, as used herein, maybe the actual location of the device (e.g., x, y, and/or z coordinates),an estimated or approximate location of the device, or information thatcan be used to acquire or estimate the location (or approximatelocation) of the device. It should also be appreciated that the presentinvention is not limited to any particular method for determininglocation, and all methods generally known to those skilled in the artare within the spirit and scope of the present invention.

For example, in one embodiment of the present invention, the mobiledevice may acquire location information from a network device, such asradio head. Such a system is disclosed in co-pending patent applicationentitled “Multi-Standard in Building Mobile Radio Access Network,” filedon May 14, 2016 (Ser. No. 15/154,970), the contents of which areincorporated herein by reference. In particular, the disclosure of how aplurality of radio heads, located throughout a building can be used toprovide location information on a mobile device is incorporated hereinby reference.

Such a system is shown in FIG. 6, where a distributed system is used todetermine a location of a mobile device. Such a system includes at leastone mobile device 30 and at least one centralized device (e.g.,interface gateway 106 and/or radio head 102 d) in communication with aplurality of radio heads (e.g., 102 a, 102 b, 102 c). The centralizeddevice may be configured to recognize when the mobile device 30 hasentered a particular service area (e.g., entered a particular building).As the mobile device 30 moves around the service area (e.g., from floorto floor of the building), the mobile device may communicate withdifferent radio heads (e.g., 102 a, 102 b, 102 c). It is during thiscommunication that the radio head can inform the mobile device 30 and/orthe centralized device (e.g., interface gateway 106 and/or radio head102 d) of the mobile device's location (e.g., x, y, and/or zcoordinates). The mobile device's location can then be provided to thehost by the mobile device (as previously discussed), or by thecentralized device (via a separate communicate with the host device orby intercepting and modifying the mobile device's communication with thehost device).

As shown in FIG. 7, radio heads can use received power to determine thelocation of a mobile device. The received power level from a particularmobile device is measured by a plurality of radio heads 102. Since theabsolute transmitted power by the mobile device is unknown, the relativereceived signal strength at the radio heads are compared and thelocation of the mobile device can be estimated based on the relativedistances from the radio heads. In another embodiment, a time of arrivalapproach can be used (either alone or in addition a received powerapproach) to locate the position of the mobile device. In this layout,radio heads 102 will look for a special signal or signal feature andcreate a timestamp of the signal feature arrival. Using the travel timeof signals traveling through air at approximately 1 ns/ft over adistance between the device and the radio head 906, the relativeposition of the mobile device is determined. With respect to each radiohead, its position could be programmed during installation for maximumaccuracy, but the techniques described above, namely based on powermeasurement and time-of-arrival measurement, can also be applied for theradio heads to determine their own relative positions. In yet anotherembodiment (described in further detail in the co-pending application),sensors can be used to monitor the transmission from the radio head(s)102. This extra capability would allow the location measurements toremain accurate even if the radio heads are moved from the manuallyentered positions at installation.

It should be noted that the location information provided by the radioheads not only gives latitude and longitude coordinates for each mobiledevice, but also floor information, allowing a user to be even moreprecisely located by including information about their altitude. Thisinformation is particularly useful when facilitating a transaction in amulti-floor structure. As discussed above, the location informationcould be conveyed from the mobile device to the host, directly, or fromthe centralized device (e.g., interface gateway 106 and/or radio head102 d) to the host device. In other words, the centralized device (or aportion thereof) could be used to provide location information to thehost device, similar to how 911 communications are described in theapplication incorporated by reference. This can be done by either aseparate communication or by intercepting and modifying the mobiledevice's communication. Once the host has the location information, itcan function as previously discussed (i.e., with the merchant and mobiledevices).

With reference to FIG. 4, it should be appreciated that a mobile deviceoperating in accordance with embodiments of the present invention mayinclude additional, fewer, or different components. For example, amobile device that further includes a dedicated GPS processor is withinthe spirit and scope of the present invention. Further, a mobile devicethat includes at least one input 38, such as a keyboard (providing hardkeys), touchscreen (providing soft keys), camera, and/or microphone isalso within the spirit and scope of the present invention. Finally,while the transceiver(s) 50 may be configured to communicate with a hostdevice via at least one satellite 52, at least one cell tower 54, and/orat least one wireless (Internet) device 56, the communication path maynot be so direct. For example, the mobile device may be configured tocommunicate with the host device via at least one other device (i.e., anintermediate device). By way of example, a smartwatch may becommunicating with a smartphone via Bluetooth or WiFi, which in turn iscommunicating with the host via a separate communication link (see,e.g., FIG. 5). In such an embodiment, the mobile application (or hostdevice in communication therewith) could use location information ofeither device to facilitate a transaction. This is due to the closeproximity of the smartwatch (e.g., mobile device) and the smartphone(e.g., intermediate device).

One method of using location information to facilitate a transaction isdepicted in FIG. 8. Starting at step 800, login information is receivedat step 802. Login information may include user name and password, ormore secure information such as biometric data of the first party (e.g.,data on the user's fingerprints, iris, retina, facial features, speechrecognition, EKG, etc.). Login information may also include a uniquekey, or a key unique to the mobile application and/or mobile device. Thekey could be either communicated or used to encode/decode and/orencrypt/decrypt communications between the mobile application and thehost device. Once received, the login information can be used to locatethe first party's account. The first party's account is an account thatis linked to the mobile application, the mobile device, and/or at leastone payment method (e.g., the user's credit card, debit card, etc.). Thelocation of the mobile device is then determined at step 804. Locationcan be determined by the mobile application, by the host device based oninformation provided by the mobile application, or by informationprovided by a third party (e.g., the centralized device in a distributedsystem, etc.). Once determined, location is then used to identify asecond party (e.g., a merchant, a store, a kiosk, etc.) at step 806.This may be accomplished using a second party/location map stored on thehost device or information available by a third party (e.g., GoogleMaps™, etc.).

At step 808, a determination is made as to whether the second party islinked to a pending act of commerce (e.g., a pending order for goodsand/or services). Pending acts of commerce are generally orders forgoods/services that may or may not be linked to time or a time period(e.g., within a thirty second window, etc.). If the answer is “yes,”then a determination is made at step 810 on whether there is more thanone order pending. If the answer is “no,” then the first party'saccount, or payment method linked thereto, is charged for the order atstep 816. A receipt is then provided to the mobile application and/orthe merchant device at step 818 ending the method at step at 820.

If at step 808, the answer is “no,” then a menu of available acts ofcommerce (e.g., goods and/or services provided by the second party) areprovided to the mobile application at step 814. The first party (user)can then select a particular act of commerce that the user would like topurchase at step 812, and the first party's account (or payment methodlinked thereto) is charged at step 816. A receipt is then provided tothe mobile application and/or merchant device at step 818, ending themethod at step 820.

If at step 810, the answer is “yes,” then the first party (user) mayselect their order at step 812. Alternatively, the host may select thecorrect order by associating data received from the merchant deviceand/or the mobile application (e.g., user name, order number, specificlocation (e.g., cash register one), specific accessory (e.g., shoppingcart, shopping basket, etc.), time period, etc.) with a particularorder. The first party's account (or payment method linked thereto) isthen charged for the selected/identified order at step 816. A receipt isthen provided to the mobile application and/or merchant device at step818, ending the method at step 820.

It should be appreciated that the present invention is not limited tothe steps illustrated in FIG. 8, and fewer, additional, or differentsteps are within the spirit and scope of the present invention. Forexample, if only the first party is allowed to place an order (e.g., viathe application), then steps 808 and 810 may be deleted, with step 814being located between steps 806 and 812. By way of another example, ifonly the second party is allowed to place an order (e.g., via themerchant device), then step 814 may be deleted. By way of yet anotherexample, before charging the first party's account (or payment methodlinked thereto), the first party may be required to acknowledge theorder before their account is charged. By way of yet another example, ifthe first party is allowed to place an order at step 812, the method mayalso determine whether the current time is within a particular timewindow. For example, if a store or kiosk is only open from 9-5, then adetermination may be made as to whether the current time (e.g., timethat the transaction is being made, etc.) is within this window of time.This step may be performed before step 812 (e.g., immediately beforestep 812, before step 814, etc.) or after step 812, before the accountis charged at step 816. It should also be appreciated that the presentinvention is not limited to the steps being performed in the orderillustrated in FIG. 8. For example, the mobile application coulddetermine the device's location before login information is received.

As previously discussed, location information can also be used (alongwith biometric data) to authenticate the user. For example, the host mayensure that the user is at a particular (e.g., authorized) locationbefore a transaction can be processed. For example, if the user isattempting to perform an ATM transaction, the host may require that theuser (along with the mobile device) be located in front of the ATM.Similarly, if the user is attempting to perform a store transaction, thehost may require that the user (along with the mobile device) be locatedinside the store or be leaving the store. When dealing with a merchant,such a feature could be used to prevent transactions from remote (orunauthorized) locations or allow transactions from local (or authorized)locations. For example, such a feature may allow a user to withdrawmoney from an ATM only when the user is standing in front of the ATM,allowing the user to be imaged by security cameras. By way of anotherexample, the host may allow the user to perform remote transactions onlywhen the user is located at an authorized location (e.g., the user'shome, etc.). Maps for storing such information are discussed in greaterdetail below.

One method of using a mobile application to facilitate a transaction isdepicted in FIG. 9. Starting at step 900, the application is open atstep 900. The first party (user) may then enter login information atstep 904. As discussed above, the login information may include username, password, biometric data, location information, etc., and mayfurther require the use of a unique key. At step 906, the first party(user) would be provided with information associated with the location.This may include data on the second party (e.g., store name, logo, etc.)and/or data on acts of commerce (goods and/or services) provided by thesecond party. By providing data on the second party, the user canconfirm that the application is functioning properly (e.g., the storeidentified is the one that they are in, etc.). Data on the acts ofcommerce can either be a menu of available goods and/or services and/orat least one pending order. At steps 908 a determination is made as towhether multiple acts of commerce are provided (e.g., a menu of goodsand/or services, multiple pending orders, etc.) or whether a single actof commerce is provided (e.g., only one good or service is available,only one pending order, etc.). If the answer is “yes,” then the firstparty (or in an alternate embodiment, the host) must select one act ofcommerce at step 910. If the answer is “no,” then no selection isnecessary. At step 912, the single act of commerce (as provided orselected) is acknowledged. If the act (or order) is not acknowledged,then the method stops at step 916. However, if the act (or order) isacknowledged, then the first party's account (or payment method linkedthereto) is charged at step 914, ending the method at step 916.

It should be appreciated that the present invention is not limited tothe steps illustrated in FIG. 9, and fewer, additional, or differentsteps are within the spirit and scope of the present invention. Forexample, a receipt or proof of purchase may be provided to the mobileapplication and/or merchant device after step 914. By way of anotherexample, the user may need to select an option (e.g., “pay now,” etc.)to trigger matching the location with a particular act of commerce. Thismay be performed before, after, or during step 906 and would allow thesystem to more closely synch the placing of an order (e.g., by acashier) and a request for payment (e.g., by the user). By way of yetanother example, the user may have the option of selecting a time forwhen the act of commerce should be performed. This would allow, forexample, the first party to schedule a future act of commerce and mayrequire the host device determining whether the selected time is withinan acceptable window of time (e.g., during business hours, etc.). Itshould also be appreciated that the present invention is not limited tothe steps being performed in the order illustrated in FIG. 8.

FIGS. 10a-10f depict exemplary screen shots of a mobile applicationbeing used to facilitate a transaction. For example, as shown in FIG.10a , a Key2Mobile™ (or other owner of the mobile application) loginscreen may be provided to the first party. In this example, the firstparty enters a user name and password. However, other verifyinginformation may be provided or used including biometric data (e.g.,fingerprint, iris, retina, facial features, speech recognition, EKG,etc.), a unique key (which may be entered or stored on the mobile deviceand used to either uniquely identify the mobile application and/or or toencode/decode and/or encrypt/decrypt communications between the mobileapplication and the host device), etc. Once the first party logs intothe application, the application may determine a location for the mobiledevice, which may be the actual location, or an approximate (orestimated) location, and may be acquired using one or more knowntechniques (e.g., using communications with at least one cell tower,satellite, radio head, etc.).

Once the location has been determined, it can be used (either alone ortogether with other information, such as time, etc.) to authenticate theuser (or transaction) and/or identify a second party, such as a merchantor an entity associated with the location. Once the second party isidentified, it can be provided to the user via the application (see,e.g., FIG. 10c , “CompanyName” with logo). The user can also be providedwith options associated with the second party. In one embodiment of thepresent invention, as shown in FIG. 10c , this may include high-leveloptions that can be facilitated by the mobile application. For example,assume a user walks into a cellular telephone store. If he/she is thereto change their cellular telephone plan, he/she may select the “performaction” 1010 option, which may include the sub-category “change cellulartelephone plan” (not shown). The host device would then notify the storeof this request for assistance. If the user is there to pay his/hercellular telephone bill, the user could select the “make payment” 1008option. The host could then use information stored in the database orinformation entered by the user (e.g., the user's telephone or accountnumber) to make a payment. If the user is there to make a purchase,he/she may select the “make purchase” 1006 option. The user may then beprovided with at least one act of commerce that the second party offers,depending on how the system, application, and/or second party isconfigured. If there is a pending order for the user (e.g., if the userjust placed an order with a cashier), then a single act of commerce maybe provided to the user. Otherwise, the user may be provided with a menuof acts of commerce offered by the second party. This is shown in FIG.10d , where the user can select from “item number 1” 1012, “item number2” 1014, and “item number 3” 1016.

The “selected item” 1018 may then be provided to the user, along with an“acknowledge purchase” 1020 option (see FIG. 10e ). If the useracknowledges the purchase, the host device will be notified, the paymentmethod linked to the user's account will be charged, and a proof ofpurchase (e.g., receipt) will be provided to the user and/or merchant,thereby completing the financial transaction (see FIG. 10f ). It shouldbe appreciated that the present invention is not limited to the screenshots depicted in FIG. 10a-f , as the screen shots are merely exemplary.Depending on (i) how the system is configured, (ii) the informationavailable to the host on the second party, and (ii) options selected bythe first party, will dictate the type of information provided to theuser and/or merchant and the order in which the information is provided.

A critical aspect of the invention is determining the location of theuser, or more particularly the user's mobile device. As discussed above,this may be the actual location of the device or a more general locationof the device. In one embodiment of the present invention, as shown inFIG. 11, the system only needs to determine which second party (e.g.,store, etc.) the device is located. If the device is located in the shop1102, then acts of commerce associated with that second party can beprovided to the user. Similarly, if the device is located in thesupermarket 1104, then acts of commerce associated with that secondparty can be provided to that user. The same holds true for the shops1106 and 1108.

In another embodiment of the present invention, as shown in FIG. 12,location of the device is used to determine more than just the secondparty. In this embodiment it is used to identify where inside the secondparty the device is located. For example, the device could be in frontof a first checkout 1202, a second checkout 1204, or a third checkout1206. This embodiment allows multiple pending orders to be linked to theproper user, or mobile application operating on a mobile device. Forexample, if the user is standing in front of the first checkout 1202,and the cashier at the first checkout just entered an order, then thatorder can be associated with the user regardless of other orders enteredby the second or third checkout 1204, 1206, or other applicationsoperating on other mobile devices.

While specific embodiments have be provided for using at least locationinformation to facilitate a transaction, the present invention is not solimited. For example, as discussed above, the present invention could beused to access secure information (e.g., from a database on a hostdevice (see, e.g., FIG. 3 at 10 and 16), from a second computer via ahost device (see, e.g., FIG. 3 at 10 and 40), etc.). For example, a usermay be allowed to access, or be provided with, secure information if theuser is in possession of, or using, a verified (mobile) computing deviceand verified login, biometric, and/or location data isprovided/acquired. In other words, a remote computing device (e.g., hostdevice, second computing device, etc.) may be configured to providesecure information to a particular (mobile) device (e.g., one that isrunning a particular (mobile) application, one that has at least oneunique key (e.g., for encoding, decoding, encrypting, decrypting, etc.),etc.) only if the remote device receive proper login data (e.g., username, password, etc.), proper biometric data (e.g., biometric data(e.g., fingerprint data, iris data, speech data, EKG, etc.)corresponding to the user, etc.), and/or proper location data (e.g.,confirming that the (mobile) computing device is at a proper orauthorized location). For example, a host device for a law firm may onlyallow devices that are located within the law firm to accessconfidential, sensitive, and/or privileged information.

By way of another example, the present invention could be used fordelivery confirmation of goods. For example, a delivery person (ordrone, robot, etc.) may only leave goods with an individual if theindividual is using a particular (mobile) device (e.g., one that isrunning a particular (mobile) application, one that has at least oneunique key, etc.) and the host device receives/confirms proper login,biometric, and/or location data. If the host device confirms that thepassword and/or biometric data matches the individual (e.g., user name,etc.), and/or the location of the (mobile) device matches the order(e.g., corresponding to the goods), then delivery confirmation isprovided. This may be accomplished by providing a receipt (e.g.,barcode, etc.) to the individual's (mobile) device, which can bepresented to (and scanned by) the delivery person (or drone, robot,etc.) for delivery confirmation.

It should be appreciated that while location data (e.g., an authorizedlocation) may be used to authenticate or verify a user (or first party),it may also (or instead) be used to authenticate or verify a deliveryperson, drone, robot, etc., ensuring that they are at the correctlocation (e.g., an authorized location) and/or allowing the item to besecured if the user (or first party) is not available. For example, asshown in FIG. 29, a delivery person delivering an item to building Awould generally leave the item on the sidewalk D, in front of door 2902.Similarly, an item for building B would be left on sidewalk D, in frontof door 2904, and an item for building C would be left on sidewalk D, infront of door 2906, etc. The present invention can be used, however, toplace the item inside the building or with a secured enclosure. Forexample, a delivery person (e.g., UPS, FedEx, Amazon Prime, etc.) mayopen or log into a mobile application on their mobile device, where theapplication identifies the location of the mobile device (as previouslydescribed). If it is determined that the delivery person is at or near(e.g., standing in front of, within a predetermined distance from, etc.)a location where the item is to be left (e.g., authorized location),then the application could be used provide access to (e.g., unlock) abuilding or a secured enclosure.

In particular, the mobile application may be used to provide locationinformation along with other data (e.g., user name, password, at leastone biometric, package identification information (e.g., a uniquebarcode (or ID) for the item, recipient data (e.g., name, address,etc.), order identification information (e.g., order number, etc.),sender data (e.g., name, address, etc.), shipping data (e.g., ship date,shipping method, etc.), etc.) to the host device. The host device couldthen use this information to determine whether access should be granted.For example, if the delivery person is authenticated or verified (e.g.,using login information, such as user name, password, biometrics, etc.)and at a location that matches or is closely related to (e.g., within apredetermined distance from, etc.) a location associated with the item(e.g., a location linked to the package or order ID, etc.), then thehost device (or an application operating thereon) would instruct anetwork-enabled device within (or in communication with) the building(see, e.g., FIG. 30 at 3002) to provide the delivery person with accessto the building or a secured enclosure associated therewith.

For example, in FIG. 29, if a person delivering an item to building A isat the authorized location (e.g., standing in front of or near door2902), then the host device may instruct a network-enabled device withinor in communication with building A to temporarily unlock door 2902,thereby allowing the person to place the item safely inside thebuilding. The network-enabled device may then relock the door 2902 afterthe item is inside. For example, the door may be relocked apredetermined time after the door is unlocked (e.g., unlock the door,wait a predetermined time (e.g., 15 seconds, etc.), relock the door). Byway of another example, the host may instruct the network-enabled devicewithin the building to relock the door (e.g., a predetermined time afterinstructions have been provided to the network-enabled device to unlockthe door, after it is determined that the delivery person (or theirmobile device) has left the building or the authorized location, etc.).

In situations where access to the building (or the main portion thereof)is not desirable (e.g., due to pets or for other security reasons), thepresent invention can be used to grant access to only a portion of thebuilding or to a secured enclosure associated therewith. For example, ifa person delivering an item to building B is at the authorized location,then the host device may instruct a network-enabled device within or incommunication with building B to temporarily unlock door 2904, wheredoor 2904′ remains locked. By doing this, the person only has access toa landing or airlock, and does other portions of the building, i.e.,portion B′. By way of another example, if a person delivering an item tobuilding C is at the authorized location, then the host device mayinstruct a network-enabled device within or in communication withbuilding C to temporarily unlock secured enclosure 2906′, where door2906 remains locked. By doing this, the person only has access to thesecured enclosure, and does not have access to the building itself.

In determining whether the mobile device is at an authorized location,the application could use one or more known techniques, including thosedepicted in FIG. 5. For example, the mobile device (or applicationoperating thereon) could use cell towers or satellites to determine itslocation. Also, or alternatively, a WiFi-based positioning system couldbe used to determine the device's location. For example, as shown inFIG. 30, a building 3000 may have a plurality of wireless access points(or WiFi hotspots) (e.g., 3004 a, 3004 b, 3000 c) and a network-enableddevice 3002 in communication with at least one door locking/unlockingmechanism 3006. A mobile device (or application operating thereon) canthen use signal strengths of and identifiers (e.g., SSID, MAC address,etc.) for the access points and a corresponding database (e.g.,associating each access point with its location) to determine thedevice's location. If the mobile device is at an authorized location,then the network-enabled device 3002 is instructed (e.g., by the hostdevice, etc.) to unlock door 3008. This may be done by disassociatingportions 3006 a (e.g., deadbolt, etc.) and 3006 b (e.g., door jam, etc.)from one another, or by unlocking door handle 3006 c.

It should be appreciated that FIGS. 29 and 30 are not intended to limitthe present invention, but merely to provide examples of how the presentinvention can be used to secure the delivery of items when the recipientis not available. As such, other embodiments are within the spirit andscope of the present invention. For example, other secured enclosures(e.g., lockers, etc.), other methods for providing access to suchenclosures (e.g., remotely-located, network-enabled access points), andother access-granting factors (e.g., time, where access is only grantedduring a time (or window) when the item is expected to be delivered),are within the spirit and scope of the present invention.

In alternate embodiments, a receipt may also (or instead) be provided toa mobile device carried by the delivery person. If the goods areelectronic in nature, delivery confirmation may also (or instead) beprovided to the goods, where delivery confirmation results in at leastone function being performed. For example, in the case of a vehicle, thevehicle may require delivery confirmation before it allows entry and/oroperates properly. By way of another example, in the case of a computingdevice (laptop, smartphone, etc.), the device may require deliveryconfirmation before it operates properly.

As discussed above, in one embodiment of the present invention, themobile device may be a wearable device, such as a smartwatch (see FIG.13). While a wearable device may function similarly to the moregeneralized mobile device (discussed above), it may differ in howinformation is provided to the user. This is due to the fact thatwearable devices are generally small, and therefore have limited screensizes. As such, the amount of information that can be presented to (orreceived from) a user is limited.

FIGS. 14a-14e depict exemplary screen shots of a mobile applicationbeing used on a wearable device to facilitate a transaction. Forexample, as shown in FIG. 14a , a simplified login screen may beprovided to the first party. In this example, the first party enters aPersonal Identification Number (PIN) or password associated with theuser's account. However, other verifying information may also (oralternatively) be provided and/or used including name, biometric data(e.g., fingerprint, iris, retina, facial features, speech recognition,EKG, etc.), a unique key (which may be entered or stored on the mobiledevice and used to either uniquely identify the mobile applicationand/or or to encode/decode and/or encrypt/decrypt communications betweenthe mobile application and the host device), etc. Once the first party'saccount is identified, the application may determine a location for themobile device (see FIG. 14b ), which may be the actual location, or anapproximate (or estimated) location, and may be acquired using one ormore known techniques (e.g., using communications with at least one celltower, satellite, radio head, etc.).

Once the location has been determined, it can be used (either alone ortogether with other information, such as time, etc.) to authenticate theuser (or transaction) and to identify a second party, such as a merchantor an entity associated with the location. Once the second party isidentified, it can be provided to the first party via the application(see, e.g., FIG. 14c , “CompanyName” with logo), along with an option1404 to acknowledge the second party (i.e., acknowledge that theidentified company is the correct company). In one embodiment, the firstparty (e.g., wearing the wearable device) may approach (physically) thesecond party (or an employee, agent, or kiosk thereof or associatedtherewith) and make a purchase (e.g., via a POS device). The purchasemay then be provided to the host device (e.g., from the POS device), anddisplayed to the first party (e.g., via a “Transaction” icon 1406). Thefirst party may then have the option of confirming the order (e.g., viaan “Acknowledge Transaction” button 1408). If the order is confirmed,then a payment method (e.g., linked to the first party's account,selected by the first party from a list of available options (notshown), etc.) may be charged (if appropriate), and a receipt will beissued to the first party, which may include transaction information1406 and/or a unique barcode 1410. Similar information may also beprovided to the second party (or the POS device), confirming thatpayment has been received, and that goods/services (as purchased,requested, etc.) should be rendered.

It should be appreciated that the present invention is not limited tothe screen shots depicted in FIG. 14a-e . Depending on (i) how thesystem is configured, (ii) the information available to the host on thesecond party, (iii) the type of mobile device used (the mobileapplication may be configured to detect the type of mobile device andshare this information with the host device), and (iv) options selectedby the first party, will dictate the type of information provided to theuser and/or merchant and the order in which the information is provided.For example, instead of interacting with an employee, agent, or kiosk tomake a purchase, the first party may use the mobile application toselect at least one good/service from a plurality of goods/servicesoffered by the second party. To do this, the application may provide thefirst party with the plurality of goods/services offered by the secondparty. Depending on the type of device that is being used (e.g.,smartphone, smartwatch, etc.), the plurality of goods/services may beshown on one screen (see, e.g., FIG. 10d ), or may be cycled through bythe first party (e.g., by clicking a “next” or “->” button(s)) (notshown)). Once a selection has been made, the first party may be allowedto confirm the purchase (see, e.g., FIG. 14d ) and/or may receive areceipt for the purchase (see, e.g., FIG. 14e ).

As mentioned above, when it comes to a wearable device, screen size maybe limited, and may thereby limit the amount of information that can bedisplayed to the first party at one time. As shown in FIG. 15a , thewearable device 1300 may be configured to display both first and secondcontent 1502, 1504 on the device's screen (either simultaneously, asshown, or sequentially, as described above). Also, or alternatively, thesecond content 1504 could be displayed on the device's screen, while thefirst content 1502 is displayed elsewhere (or vice versa). For example,as shown in FIGS. 15b and 15c , the first content 1502 could beprojected using a projection device, e.g., onto a surface, such as theuser's hand, the user's wrist, a wall, a table, or a windshield, or intothe air (e.g., as a hologram). This can be accomplish using technologydeveloped by Samsung™ (e.g., Galaxy Beam™), Apple™ (e.g., Miroir HDProjector™), Cicret™ (e.g., Bracelet™), Microsoft™ (e.g., HoloLens™),Virtual Presence™, Magic Leap™, Daqri Holographics™, and Holoxia™, toname a few.

It can also be accomplished using a separate display device. Forexample, if a wearable device (e.g., a smartwatch) is in communicationwith the host device via an intermediate device (e.g., a smartphone),then second content may be displayed on the wearable device's screen,and first content may be displayed on the intermediate device's screen(or vice versa). In another example, as shown in FIG. 16, a wearabledevice 1300 (e.g., a smartwatch, etc.), which is connected to the hostdevice 10 via a WAN 20, may be configured to display the second content1504, while the first content 1502 is displayed on a network-enableddevice 1600 (or vice versa). In other words, information that is to bepresented to the first party can be done so using the wearable device1300 and/or the network-enabled device 1600, which may be owned and/oroperated by the first party, the second party, or a third party.

For example, as shown in FIG. 18a , an ATM may be configured to displaythe first content (e.g., data on the first party (e.g., John Smith,accounts held by John Smith, etc.), the second party (e.g., Bank ofAmerica, etc.), goods/services offered by the second party (e.g.,Withdraw Funds, Transfer Funds, etc.), and/or the first party'stransaction request (e.g., Withdraw $20 from John Smith's checkingaccount, etc.). The first party could then use the wearable device tofacilitate the transaction, where the wearable device is configured todisplay the second content (e.g., data on the first party, second party,goods/services offered by the second party, the first party'stransaction request, data related thereto, etc.). By way of exampleonly, a first party, standing in front of an ATM, may open and log intothe mobile application. Using the location of the wearable device, themobile application may identify the ATM, and ask the first party (viathe wearable device's display) to confirm whether they would like to usethe application to facilitate a transaction with the ATM (see, e.g.,FIG. 14c ). If the first party answers in the affirmative, the ATM maythen ask the first party (via the ATM's display) to enter their PersonalIdentification Number (PIN). The first party may then enter their PIN onthe wearable device (see, e.g., FIG. 14a ). If the provided PIN matchesa predefined PIN (as determined by the host device, the ATM, thefinancial institution, etc.), the host device may then provide the firstparty with a plurality of options, such as withdraw money, make atransfer, etc. The options can either be provide on the wearable device(see, e.g., FIG. 10d ) or provided on the ATM. However, if the optionsare provided on the ATM, the options should correspond to entries on thewearable device (e.g., press “1” for withdraw, “2” for transfer, etc.).By selecting the appropriate option, which may further require selectingthe appropriate sub-option (e.g., enter the amount to withdraw, etc.),the wearable device may ask the first party to confirm the requestedtransaction (see, e.g., FIG. 14d ). A receipt may then be provided tothe first party (e.g., via the wearable device (see, e.g., FIG. 14e ),via a printout from the ATM, etc.), and the requested transaction isperformed (e.g., $20 is dispensed from the ATM, etc.).

As shown in FIG. 18b , the same technology could be used to interactwith a gaming device, such as a slot machine. For example, while thefirst party is seated in front of a gaming device, the mobileapplication could be used to add money to the gaming device (instead ofinserting money or a voucher), retrieve money from the gaming device(instead of dispensing money or a voucher), and/or play the gamingdevice. If a financial transaction is requested, then the sequence ofsteps may be similar to those used on an ATM (see above). If, however,the wearable device is used to play the game, the gaming device may beused to display options, and the wearable device may be used to selectfrom corresponding entries (e.g., press “1” for slots, “2” for videopoker, etc.). It should be appreciated that, depending on the level ofinteraction, the wearable device may allow the first party to selectfrom corresponding sub-entries. For example, if the gaming device is (oris functioning as) a slot machine, the first party may press “1” (or“spin”) to spin the wheels. If the gaming device is (or is functioningas) a video poker machine, then the first party may press any number (orbutton) to deal the cards, press a corresponding number to hold a card(e.g., press “1” to hold the first card, “2” to hold the second card,etc.), and any other digit (“0,” “6-9,” “#,” or “*”) to deal replacementcards.

As shown in FIG. 18c , the same technology could be used to interactwith a network-enabled monitor, a network-enabled television, or anetwork-enabled Set Top Box (STB) connected to a television. Forexample, while the first party is in a hotel room or on an airplane, themobile application could be used to watch a movie, play a video game,etc. If the first party wants to watch a movie, the TV (or STB) mayprovide the first party with a plurality of options 1806, 1808. Asbefore, the wearable device may be used to select from correspondingentries, which may be individual movies (e.g., press “1” for the firstmovie, “2” for the second movie, etc.), or may allow the first party todrill down to a plurality of movies (e.g., press “1” for new releases,“2” for still in theater, etc.). It should be appreciated that theforegoing examples are just that—examples—and are not limitations of thepresent invention. As discussed above, the present invention could beused in conjunction with any third-party, network-enabled device,regardless of the goods/services that are being provided.

In one embodiment of the present invention, as shown in FIG. 17, thewearable device may further include at least one sensor 1706 (e.g., forsensing heart data, EKG data, etc.), at least one camera 1704 (e.g., forcapturing image/video data of the first party), and/or at least onemicrophone 1702 (e.g., for capturing audio data of the first party). Notonly do these features increase flexibility (e.g., allow the first partyto speak their selection, etc.), but they can also be used to enhancesecurity. For example, audio data may be used along with voicerecognition software (e.g., on the host device, etc.) to confirm thatthe first party is who he/she claims to be. Similarly, image/video datacan be used along with facial and/or retinal recognition software (e.g.,on the host device, etc.) to confirm that the same. Sensor data (e.g.,heart rate data, EKG data, etc.) may be used to confirm that thewearable device is merely being worn at the time the mobile applicationis being used, or it too could be used to uniquely identify the firstparty. For example, the University of Toronto has developed technologythat turn one's EKG pattern into a unique key, or password that can beused for unique identification. By having possession of the mobiledevice, having the mobile device at a location where the transaction isto be facilitated, knowing the password, and having (or being able toprovide) identifiable biometric data, the mobile application can be usedto carry out the most sensitive transactions, such as banking and otherfinancial transactions. And if the mobile device includes a camera 1704,the mobile application may be configured to capture a photo of the userwhile the transaction is being carried out. The photo could then beprovided to the host, analyzed (to ensure that facial features arerecognizable, preventing the user from blocking their face, using thedevice without proper lighting, etc.), and stored together withtransaction information. Such use of the mobile device, or the camerafeature thereof, should help detour fraudulent usage of the presentinvention.

One method of using location information to facilitate a transaction isdepicted in FIG. 19. Starting at step 1900, login information isreceived at step 1902. Login information may include user name andpassword, or more secure information such as biometric data of the firstparty (e.g., data on the user's fingerprints, iris, retina, facialfeatures, speech recognition, EKG, etc.). Login information may alsoinclude a unique key, or a key unique to the mobile application and/ormobile device. The key could be either communicated or used toencode/decode and/or encrypt/decrypt communications between the mobileapplication and the host device. Once received, the login informationcan be used to locate the first party's account. The first party'saccount is an account that is linked to the mobile application, themobile device, and/or at least one payment method (e.g., the user'scredit card, debit card, etc.). The location of the mobile device isthen determined at step 1904. Location can be determined by the mobileapplication, by the host device based on information provided by themobile application, or by information provided by a third party (e.g.,the centralized device in a distributed system, etc.). Once determined,at step 1906, location is then used to identify a second party (e.g., amerchant, a store, a kiosk, etc.), and in certain embodiments, toauthenticate the user (or transaction). This may be accomplished using asecond party/location map stored on the host device or informationavailable by a third party (e.g., Google Maps™, etc.).

At step 1908, the identified party (e.g., company, etc.) is provided (ordisplayed) to the first party. At step 1910, a determination is made bythe first party as to whether the identified party is the correct party(e.g., the company that the first party wishes to do business with,etc.). If the answer is “no,” then the first party may be presented withother options at step 1914, which may include other companies that arenearby (e.g., within a predetermined distance from the mobile device).If, at step 1910, the answer is “yes,” then a pending transaction (e.g.,a transaction pending with the cashier, entered into the POS, etc.) maybe provided (or displayed) to the first party at step 1912. At step1916, a determination is made by the first party as to whether thepending transaction (as displayed) is correct. If the answer is “no,”then the first party may be presented with other options at step 1914,which may include other pending transactions, or a request to enterinformation that will allow the system to identify the correcttransaction. If, at step 1916, the answer is “yes,” then a receipt isprovided (or displayed) to the first party and/or the second party atstep 1918, ending the method at step 1920.

It should be appreciated that the present invention is not limited tothe steps illustrated in FIG. 19, and fewer, additional, or differentsteps are within the spirit and scope of the present invention. Forexample, if the transaction is a purchase of a good/service, a paymentmethod (e.g., linked to the first party's account, etc.) may be chargedbefore the receipt is provided to the first and/or second party at step1918. By way of another example, if the first party is allowed to usethe mobile application to select the transaction, then a plurality ofavailable transactions may be provided (or displayed) to the firstparty, and the first party may have an opportunity to select thetransaction prior to (or instead of) steps 1912, 1916. By way of yetanother example, if the first party is allowed to use the mobileapplication to select the transaction, then the method may alsodetermine whether the time of the selection is within a particular timewindow. For example, if a store is only open (or allowed to do businesswith the mobile application) from 9-5, then a determination may be madeas to whether the time of the transaction (e.g., selection, request,etc.) is between 9:00 AM and 5:00 PM.

By way of yet another example, additional login information may berequested by the second party after the second party has been identifiedat step 1906. For example, if the second party is a financialinstitution, the first party may be required to enter a PersonalIdentification Number (PIN) before the mobile application can be used tofacilitate a financial transaction. In this example, the PIN would needto be authenticated (e.g., by the host device, the merchant device, thefinancial institution, etc.) before the first party is allowed to select(or complete) a financial transaction. For example, if the first partyis standing in front of an ATM, the first party may be required to entertheir PIN, which may be provided to the second party (e.g., the ATM, thefinancial institution, etc.) via the host device. The second party maythen take steps to authenticate the PIN (e.g., determine whether theprovided PIN matches a previously provided PIN), and notify the hostdevice of the results. If the PIN is not authentic, then the host devicemay notify the first party, and end the method. However, if the PIN isauthentic, then the host device may provide certain transaction optionsto the first party (e.g., via the ATM and/or the mobile device, etc.).It should also be appreciated that the present invention is not limitedto the steps being performed in the order illustrated in FIG. 19. Forexample, the mobile application could determine the device's locationbefore login information is received, options could be provided earlier,or later, etc.

It should further be appreciated that while the first party may use themobile device to provide information to the host device and/or thesecond party, any device (e.g., the mobile device, an intermediatedevice, or a network-enabled device (e.g., owned or operated by thesecond party)) can be used to provide information to the first party.For example, if at step 1914, additional information needs to beprovided to the first party, the method continues step 2000 (see FIG.20), where first content is provided on a first screen at step 2002, andsecond content is provided on a second screen at step 2004. For example,in the case of an ATM, the first screen (e.g., on the ATM) may be usedto provide a series of options to the first party (e.g., withdraw,transfer, etc.), and the second screen (e.g., on the mobile device) maybe used to provide corresponding selections to the first party (e.g.,press “1” for withdraw, “2” for transfer, etc.). At step 2006, adetermination is made as to whether a selection has been received. Ifthe answer is “no,” then the method returns to step 2002. If the answeris “yes,” then at least the second screen is updated, preferablyidentifying the selection or providing the first party with a pluralityof sub-options. The first party may then be allowed to acknowledge theselection at step 2010. If, at step 2010, the answer is “no,” then themethod may return to step 2002. If, at step 2010, the answer is “yes,”then a receipt may be provided to the first and/or second party at step2012, ending the method at step 2016.

Again, it should be appreciated that the present invention is notlimited to the steps illustrated in FIG. 20, and fewer, additional, ordifferent steps are within the spirit and scope of the presentinvention. For example, if the transaction is a purchase of agood/service, a payment method (e.g., linked to the first party'saccount, etc.) may be charged before the receipt is provided to thefirst and/or second party at step 2012. The method may also determinewhether the time of the selection is within a particular time window,may update the first screen (instead of or in addition to the secondscreen) in step 2008, and certain steps (e.g., 2002 and 2010) may berepeated if additional selections are required (e.g., to drill down(e.g., at an ATM, the first party may select “withdraw,” followed by“checking,” followed by “$20,” etc.), to request a map for an itembefore the item is placed in a shopping cart (e.g., where the map isreplaced by information on the item once the item is placed in the cart,etc.), etc.

As discussed above, the host may store (or have access to) (e.g., via alocally and/or remotely located memory device or database) a map (e.g.,look-up table, etc.) that can be used to identify (or look-upinformation related to) a user's account, a second party (e.g.,merchant), or a particular transaction. Such a map is shown in FIG. 21,where information is linked together using fields (e.g., rows, columns)that are related or linked to one another, using, e.g., spreadsheet ordatabase technology.

For example, a First User 2102 a (e.g., User 1, which may be identifiedby a unique identifier, etc.) may be linked to User Account Information2104 a (e.g., name, address, phone number, email address, preferences,etc.), User Login Information 2106 a (e.g., login name, password, etc.),User Biometric Data 2108 a (e.g., fingerprint, retina, iris, facial,voice, EKG, etc.), User Payment Information 2112 a (e.g., credit card,debit card, bank account, host account, preferences on which account touse (e.g., default account), etc.), and User Authorized LocationInformation 2112 a (e.g., at least one user location (e.g., X, Y, and/orZ coordinates (e.g., GPS coordinates, such as latitude, longitude and/oraltitude), address, city, state, zip code, etc.) (e.g., the user's home,etc.), proximity data (e.g., within the user location, within a one mileradius from the user location, etc.). Similar data can be stored onother users (e.g., User n, 2102 b).

As discussed above, the User Authorized Location Information 2112 a maybe used in conjunction with location information provided by the mobileapplication to determine whether the user (including the mobile device)is at an authorized location. For example, if the User AuthorizedLocation Information 2112 a includes the user's home address and aproximity radius of a one mile, then the user may be determined to be atan authorized location (e.g., for remote transactions) if the user (orthe user's mobile device) is within a one-mile radius of the user's homeaddress, or GPS coordinates associated therewith, when a transaction isbeing carried out. By way of another example, if the User AuthorizedLocation Information 2112 a includes the user's home zip code and aproximity value of “within the user location,” then the user may bedetermined to be at an authorized location if the user (or the user'smobile device) is within the user's zip code, or GPS coordinatesassociated therewith, when a transaction is being carried out. Otherinformation may be linked to each user. See, e.g., FIGS. 28 and 29(discussed in greater detail below).

Similar information can also be stored on a particular merchant. Forexample, a First Merchant 2102 c (Merchant 1, which may be identified bya unique identifier, etc.) may be linked to Merchant Account Information2104 c (e.g., name, address, phone number, website, email address,goods/services offered for sale, pending orders, etc.), at least oneMerchant Time Window 2106 c (e.g., hours of operation, etc.), a MerchantRemote Access Policy 2108 c (e.g., whether goods/services can bepurchase remotely, e.g., from the user's home, etc.), Merchant LocationInformation 2110 c (e.g., at least a first merchant location (e.g., X,Y, and/or Z coordinates (e.g., GPS coordinates, such as latitude,longitude and/or altitude), address, city, state, zip code, etc.),proximity data (e.g., within the first merchant location, within onehundred feet from the first merchant location, etc.), etc.), andMerchant Authorized Location Information 2112 c (e.g., at least a secondmerchant location (e.g., X, Y, and/or Z coordinates (e.g., GPScoordinates, such as latitude, longitude and/or altitude), address,city, state, zip code, etc.), proximity data (e.g., within two feet fromthe second user location, etc.), etc.). Similar data can be stored onother merchants (e.g., Merchant n, 2102 d).

As discussed above, the Merchant Location 2110 c may be used along withlocation information provided by the mobile application to identifyMerchant 1. For example, if the Merchant Location 2110 c includes anaddress of a store operated by Merchant 1 and a proximity radius of onehundred feet, and the user (or the user's mobile device) is at alocation within a one hundred foot radius of the store's address (e.g.,the location information provided to or by the mobile application iswithin a one hundred foot radius of the store's address), then Merchant1 will be identified by the host device, and information on Merchant 1(e.g., Merchant Account Information 2104 c, etc.) will be provided tothe mobile application and displayed to the user. This same informationcan also be used to authenticate the user or transaction. In otherwords, if the user (or the user's mobile device) is within aone-hundred-foot radius of the store's address, then the user (or theuser's mobile device) may be considered to be at an authorized location.In other embodiments, other information can be used to authenticate theuser or transaction. For example, if the Merchant Authorized LocationInformation 2112 c includes a proximity radius of ten feet (e.g.,identifying (roughly) the perimeter of the store, etc.), then the userwill only be considered to be at an authorized location if the user iswithin a ten-foot radius of the store's address, or associated GPScoordinates. It should be appreciated that while proximity has beenexemplified using a radius, the present invention is not so limited, andany method of identifying a particular area (e.g., using plural GPScoordinates, an X proximity value, a Y proximity value, etc.) is withinthe spirit and scope of the present invention.

The map 2100 may also store information on individual transactions. Forexample, a First Transaction 2102 e (Transaction 1, which may beidentified by a unique identifier, etc.) may be linked to a Merchant2104 e (e.g., a particular merchant, such a Merchant 1, a particularuser, such as User n, etc.), a User 2106 e (e.g., a particular user,such as User 1, etc.), a Transaction Date 2108 e (e.g., a date of thetransaction, etc.), a Description 2110 e (e.g., a description of thetransactions, such as goods/services, etc.), and Payment Information2112 e (e.g., cost of the transaction, a payment method used to pay forthe transaction, etc.). Similar data can be stored on other transactions(e.g., Transaction n, 2102 f).

It should be appreciated that the present invention is not limited tothe map depicted in FIG. 21. A database having additional, fewer, ordifferent fields is within the spirit and scope of the presentinvention. For example, payment information could be stored by themerchant, and not processed (or stored) by the host device. By way ofanother example, the transaction records may further include at leastone image of the transaction. Such an image could be provided by themerchant (e.g., using security cameras operated by the merchant) or theuser (e.g., using a camera on the mobile device) and linked togetherwith the transaction, making it available upon request.

The present invention can also be used to enhance a user's shoppingexperience when a user is shopping at a brick-and-mortar store. Forexample, as shown in FIG. 22, a mobile device operated by a first partymay be in communication with a host device 10 and a merchant device 70operated by a second party via a wide area network (WAN), such as theInternet 20. In this embodiment, as previously discussed, the hostdevice 10 may also be in communication with at least one third-partydevice (not shown) via the network 20, such as a financial institution.See, e.g., FIG. 3. What distinguishes this embodiment from theembodiment depicted in FIG. 3, is that the host device 10 in further incommunication with a shopping cart 60 via the network 20, which may ormay not be operated by the second party.

It should be appreciated that in alternate embodiments, the mobiledevice 30 may also (or alternatively) be in communication with theshopping cart 60 either directly (e.g., via 74, such as Bluetooth, RF,WiFi, etc.) or indirectly (e.g., via network 20, via host device 10,etc.), and the merchant device 70 may be in communication with theshopping cart 60 either directly (e.g., via 72, such as Bluetooth, RF,WiFi, etc.) or indirectly (e.g., via network 20, via host device 10,etc.). Similarly, the mobile device 30 may be also (or alternatively) bein communication with the merchant device 70 directly and/or indirectly.Thus, for example, a mobile device 30 that communicates with the hostdevice 10 via the network 10, where the host device 10 communicates withthe merchant device 70 and the shopping cart 60 via the network 20, iswithin the spirit and scope of the present invention. Similarly, amobile device 30 that communicates with the shopping cart 60 eitherdirectly (e.g., via Bluetooth, RF, WiFi, etc.) or through the merchantdevice 70 (e.g., where the mobile device 30 communicates with themerchant device 70 via the network 20 and the merchant device 30communicates with the shopping cart 60 directly (e.g., via Bluetooth,RF, WiFi, etc.)) is also within the spirit and scope of the presentinvention.

FIG. 23 shows an example of a shopping cart in accordance with oneembodiment of the present invention. In this embodiment, the shoppingcart 60 is configured for movement on a substantially flat surface. Aswith most carts, it includes a basket 2302, a plurality of wheels 2304,2306, and at least one handle 2308. However, the cart 60 also includesintelligence. For example, it may include an on-board computer 2300(e.g., for receiving, transmitting, and processing information) and adisplay 62 (e.g., for displaying information to the first party). Inalternate embodiments, it may also include components for determiningitems that have been placed in the cart 60. Preferably, a detector 62′is used to identify items that have been (or are being) placed withinthe cart 60. For example, the detector 62′ may be a barcode scannerconfigured to scan barcodes on outer surfaces of items, an RFIDinterrogator configured to interrogate RFID tags on (or within) items,or a camera configured to capture visuals of items, whereitem-recognition software is used to identify items that are beingimaged.

Other technology can be used to confirm that an item has indeed beenplaced within the cart. For example, a scale 68 may be positionedbetween the basket 2302 and the wheels 2304, 2306. Weight (or changetherein) can be used to verify that an item has been placed inside thecart 60 (e.g., an increase by 6 ounces may confirm that a 6 ounce can oftomato paste has been placed inside the cart 60, etc.). By way ofanother example, an infrared (IR) light generator 64 (e.g., IR LED,etc.) and an IR light detector 64′ (e.g., photocell, etc.) may be usedto detect when items have been placed inside (or taken out of) the cart60. By transmitting at least one IR beam over an upper surface 65 of thecart 60, a break (or discontinuity) in the beam may confirm that an itemhas been added to (or removed from) the cart 60.

It should be appreciated that the present invention is not limited toany particular way of determining whether an item has been placed insidethe shopping cart, and all ways generally known to those skilled in theart are within the spirit and scope of the present invention. Forexample, cameras positioned around the store may be used (together withitem-recognition software) to identify individual items that are beingplaced inside the cart. By way of another example, barcode technology(e.g., together with weight, etc.) can be used to identify individualitems that are being placed inside the cart (e.g., similar to currentself-checkout stations, etc.).

It should also be appreciated that the present invention is not limitedto the type, number, and location of components (electrical orotherwise) included on the cart. For example, the shopping cart mayinclude at least one connector 66, 66′ for transmitting power andinformation to/from the cart when the cart is docked. By placingconnectors in both the front and the rear, carts can be nested, attraditional done, creating a continuity for power and information (i.e.,a first cart's front connector is connected to a docking station, asecond cart's front connector is connected to the first cart's rearconnector, etc.). This would allow each cart (or a battery thereon) tobe charged and to receive and/or transmit information to the merchantdevice (e.g., updating software to the cart (e.g., available items,prices, locations, etc.), downloading data (e.g., purchases made via thecart, customers using the cart, etc.), etc. By way of another example,the cart itself may be a small, hand-held basket (see FIG. 24) asopposed to a wheelable shopping cart.

In one embodiment of the present invention, as shown in FIG. 25, thecart (regardless of its configuration) includes a processor 2302, amemory 2304, at least one transceiver 2306 (e.g., Bluetooth, RF, WiFi,etc.), a display 62, and an input device 63 (e.g., keyboard,touchscreen, etc.), wherein the transceiver(s) 2306 allows the cart tocommunicate with the mobile device 30, the merchant device 70, and/orthe host device 10, the memory 2304 stores data, e.g., code for theprocessor 2302, items available for purchase (e.g., names, prices,location, etc.), items placed into the cart (e.g., names, prices,running total, running weight, etc.), customer data (e.g., customername, etc.), etc., and the display 62 and input device 63 are used,respectively, to provide information to and receive information from thefirst party. The cart may also include a scanner 2308 (or the like) foridentifying items that have been (or are being) placed into the cart. Asstated above, FIG. 25 is merely exemplary, and a cart having fewer,additional, or different components (e.g., an optical recognition device(e.g., camera) instead of a scanner, multiple memory devices, etc.) iswithin the spirit and scope of the present invention.

Preferably, each cart has its own unique identifier (ID), allowing thesystem to identify one cart from a plurality of carts, i.e., identifyingthe cart that is being used by the first party. As shown in FIG. 26a ,the user may enter the cart's ID into the mobile device (e.g., via thedevice's keypad, etc.), where the cart's ID is presented on the display62 and/or a sticker on the cart 60. The ID can then be provided to thehost device (not shown), allowing the cart to be linked (or synced) tothe shopping session. This information may also (or alternatively) beprovided to the merchant device (not shown) if the merchant device isresponsible for communications with the cart.

It should be appreciated that the present invention is not limited toentering (manually) the cart's ID into the mobile device, and other waysof identifying the cart are within the spirit and scope of the presentinvention. For example, the application operating on the mobile devicemay capture the cart's ID (e.g., via the mobile device's camerafeature), which may be displayed in human-readable form (e.g., 123456),or machine-readable form (e.g., a barcode). By way of another example,the cart may communicate (e.g., broadcast) its ID to the mobile device(e.g., using Bluetooth, NFC, etc.).

Once a shopping session is established, and the devices (mobile device,merchant device, host device, shopping cart) are linked, the first partycan use the mobile device and/or the shopping cart (or the displayand/or input device portions thereof) to enhance their shoppingexperience. It should be appreciated that the first party may interactwith either the mobile device (or the screen portion thereof) (hereinthe first display) or the shopping cart (or the screen portion thereof)(herein the second display) to acquire additional information, dependingon how the system is configured. For example, the first party may chooseto interact with the first display (so as to not touch the second(public) display), or the first party may choose to interact with thesecond display, which is more conveniently location (e.g., the mobiledevice may be in the first party's pocket, purse, etc.). It should beappreciated that while the user may interact with either display, thesecond display is preferably used to present information to the user, asit may be larger and more conveniently located.

As shown in FIG. 26b , the first party may be presented with a pluralityof options, including a map button 2602 a, a search button 2602 b, and acoupon button 2602 c. Other buttons or interactable icons are within thespirit and scope of the present invention. If the map button 2602 a isselected, a map of the store may be presented on the second display 26.See FIG. 26c . The map may include a location for the first party 2604 aand locations for items (or categories of items) available for purchase(e.g., bakery 2604 b, frozen food 2604 c, etc.). To do this, the cartmust have access to map data (e.g., stored in its memory, provided inreal-time by the merchant device, etc.) and user-location data. Thelatter may be determined by determining the location of the mobiledevice or the location of the shopping cart. Previously discussedlocation methods may be used (e.g., WiFi-based positioning system, etc.)to determine locations of the mobile device and the shopping cart.However, because the store has a known footprint, other locationtechniques are available for the cart that are not available for themobile device.

For example, the cart may be configured to read location informationtransmitted (or scannable) at various locations throughout the store. Byway of example, at least one bakery identifier may be (a) posted forscanning (e.g., barcodes, etc.) or (b) transmitted (e.g., via IR, etc.),allowing the cart to locate itself as it is moved throughout the bakeryportion of the store. In other words, the cart may understand thatlocation 001 (read from a first barcode, transmitted from a first IRtransmitter, etc.) is in the bakery, in front of the bagels, location002 (read from a second barcode, transmitted from a second IRtransmitter, etc.) is in the bakery, in front of the donuts, etc. Bypositioning a plurality of barcodes or IR transmitters throughout thestore, the cart (using at least one barcode scanner or IR receiver) canautonomously determine its location as it is move throughout the store.

With reference back to FIG. 26b , if the search button 2602 b isselected, the first party may be presented with a field 32′ for enteringa search query (e.g., “mashed potatoes”) via a keyboard 38. See FIG. 26d. A map of the store 2604 may then be presented on the second display26, which may include a location of the first party 2604 a, a locationof the search query 2604 d (“mashed potatoes”), and a route 2604 e(e.g., directions, etc.) therebetween. The route 2604 e may be providedvisually and/or audibly, providing step-by-step directions from thelocation of the first party 2604 a to the location of the search query2604 d (e.g., take a left at the Check Out, take a right after the CanGoods isle, proceed straight for 100 feet, the Mashed Potatoes arelocated on the left hand side, top shelf, 10 feet before the end of theisle, next to the Ketchup).

To provide more accuracy, a store could be laid out in a grid fashion(e.g., longitude, latitude, altitude), where items are locatable by X,Y, and/or Z coordinates. This would allow the system to provide moreaccurate directions. For example, Mashed Potatoes may be located at10/15/3, or on isle 10, 15 feet from the front of the isle, and threefeet off the ground. Markings in the store may allow the customer tomore accurately locate an item (e.g., by labeling each isle(side-to-side), distances down an isle (front-to-back), and verticaldistances (floor-to-ceiling). It should be appreciated that labels otherthan numerical (e.g., alphabetical, colors, shapes, etc.) may also (oralternatively) be used to locate an item (e.g., Mashed Potatoes may belocated at 10-Red-A, or isle 10, section “Red,” compartment A).

The present invention can also be used to provide coupons to the firstparty. For example, as shown in FIG. 26e , a dairy button 2606 a couldbe used to receive dairy-related coupons, a meat button 2606 b could beused to receive meat-related coupons, a produce button 2606 c could beused to receive produce-related coupons, etc. For example, if the dairybutton 2606 a is selected, coupons for cheese, milk, eggs, and ice creammay be presented on the second display 62. By presenting coupons in thisfashion, the coupons can be general coupons, available to all, orpersonalized coupons, specific to the first party (e.g., based on priorpurchases, the first party's shopping list, etc.). In alternateembodiments, the location of the first party (or the shopping cart) mayalso (or alternatively) be used to identify coupons to be presented tothe first party (e.g., coupons for wine may be presented to the firstparty when they are in the alcohol aisle, etc.).

In order to enhance a first party's shopping experience, the host and/ormerchant device may store information on prior purchases. For example,as shown in FIG. 28, information may be stored that links individualusers to recent purchases and coupons selected based on those purchases.For example, if User 1 2802 a recently purchased Lucerne ice cream 2804a, then a coupon for Ben & Jerry's ice cream 2806 a may be presented tothe user upon a subsequent visit (e.g., in response to selecting thedairy button 2606 a, in response to being in the frozen food aisle, inresponse to entering the store, etc.).

As shown in FIG. 29, the first party may also upload (or enter) theirshopping list to (or with) the host device, e.g., via the mobileapplication. This may include the item 2902 a (mayonnaise), brand 2904 a(Best Foods), type 2906 a (light), size 2908 a (64 oz), quantity 2910 a(2), price 2912 a (e.g., provided by the first party or the host deviceand based on previous purchases, best price available, price at aparticular store, desired price, etc.), and comments related thereto2914 a (e.g., completely out, running low, etc.). This information(e.g., recent purchases, shopping list, etc.) can then be used toenhance the first party's shopping experience. For example, as shown inFIG. 26f , the second display 62 may notify the first party of an itempreviously purchased, and the mobile device 30 may be used to indicatewhether the item should be purchased again. If yes, a map may bepresented on the second display 62, showing a location for the item. Ifno, other information concerning the item may be presented on the seconddisplay 26. For example, the second display 62 may notify the firstparty that the item is currently on sale (see FIG. 26g ) and/or the itemis on the first party's shopping list (see FIG. 26h ). It should beappreciated that the screen shots provided herein are merely exemplary,and that other screen shot are within the spirit and scope of thepresent invention. For example, if the user is shopping for items offtheir shopping list (see FIG. 29), the second display 26 may guide theuser through the store in an orderly fashion to acquire the items. Thismay be done automatically by comparing items on the list to locations ofthose items in the store and routing the user through the store tominimize travel distance, perhaps taking into consideration otherfactors (e.g., starting location, parking location, congestion, specialcare items (e.g., expensive, hot, cold, heavy, etc.), which may beacquired last, etc.).

As shown in FIG. 26i , once the user is done shopping (or during theshopping session), the second display 62 may be used to show items thathave been placed into the shopping cart and amounts due for the same(individually and/or cumulatively). The first party can then use themobile device 30 to confirm that these items are to be purchased. Oncethe transaction is complete (details of which are discussed above), themobile device 30 may provide the user with a receipt, which may includea time stamp (i.e., time of purchase) and be used by the first and/orsecond parties to confirm that the items have indeed been purchased.

The system may determine that the first party is done shopping bymonitoring the first party's location (e.g., whether the first party isin a check-out location, near the store exit, whether the first partyhas exited the store, etc.). The first party may also interact with themobile device to indicate that they are done shopping and would like tocomplete the transaction, or “check out.”

In order to further protect the first and/or second parties, the usermay be guided to a specific location (e.g., within the store, etc.) tocomplete their transaction, or “check out.” For example, as shown inFIG. 27a , if the first party indicates that they would like to checkout (e.g., by selecting “Y” on device 30), the second device 62 mayguide the user to a specific “check out” location (e.g., A, B, etc.).This protects the first party by requiring the first party, the firstdevice, and the shopping cart (with the second device and the goodsbeing purchased) to be at a specific location at a specific time, whichcan be captured via cameras (e.g., on the cart, in the store, etc.) ifdesired.

This also protects the second party by providing them with assurancethat the transaction has been completed (i.e., that the first party haspaid for the goods). For example, as shown in FIG. 27b , the first partymay be directed to location 2700. When the first party approaches thelocation, mechanical 2702 (e.g., door, arm, etc.), visual 2706, 2708(red light, green light, etc.), and/or audible (not shown) indicatorsmay be used to inform the first party of a time when they are toposition themselves, the first device, and/or the shopping cart atlocation 2700. Once the transaction has been completed (see, e.g., FIGS.26i and j ), similar mechanical 2704, visual 2706, 2708, and/or audible(not shown) indicators may be used to inform the first and/or secondparties of this completion (i.e., confirming payment for the goods).

It should be appreciated that other indicators are within the spirit andscope of present invention, and that different indicators may be used toprovide information to the first and second parties. For example, atleast one indicator may inform the first party that the transaction hasbeen completed and that the first party is free to leave the store,whereas at least one other indicator may inform the second party whetherthe transaction was completed. The latter may be accomplished, forexample, by presenting transaction information (e.g., accepted, denied,etc.) to a store employee via a third display. This would allow a singlestore employee to monitor several check out locations, confirming thatgoods have been paid for before individuals leave the store.

Having thus described several embodiments of a system and method forusing at least location information to facilitate a transaction, itshould be apparent to those skilled in the art that certain advantagesof the system and method have been achieved. It should also beappreciated that various modifications, adaptations, and alternativeembodiments thereof may be made within the scope and spirit of thepresent invention. The invention is solely defined by the followingclaims.

What is claimed is:
 1. A method for using at least location informationto facilitate a transaction between a first party and a second party,said transaction involving said first party purchasing at least one itemfrom said second party, comprising: receiving a request from said firstparty to opening an application on a mobile device, said applicationbeing in communication with a host device via a wide area network (WAN);receiving login information from said first party, said logininformation being used to identify an account for said first party, saidaccount being linked to at least one payment method; determining alocation of said mobile device, said location being provided to saidhost device via said WAN and used to identify said second party; usingby said host device information received from said application to linkat least one of said first party, said application, and said mobiledevice to one of a plurality of shopping carts; and displaying firstinformation to said first party via a first display device on said oneof said plurality of shopping carts, said first information including atleast information on said at least one item after said at least one itemhas been placed in said one of said plurality of shopping carts, whereindata concerning said at least one item is provided to said host deviceafter said at least one item has been placed in said one of saidplurality of shopping carts; displaying second information to said firstparty via a second display device on said mobile device, said secondinformation including at least an amount due for said at least one item,said second information being received from said host device via saidWAN; and receiving by said application an acknowledgement that saidfirst party would like to purchase said at least one item, saidacknowledgement being provided to said host device via said WAN andresulting in said payment method being used purchase said at least oneitem from said second party.
 2. The method of claim 1, wherein said stepof receiving login information from said first party comprises receivingat least a user name, a password associated with said account, and atleast one biometric of said first party.
 3. The method of claim 2,wherein said at least one biometric of said first party comprises atleast one of a fingerprint of said first party, and image of said firstparty, and audio from said first party.
 4. The method of claim 1,wherein said step of determining a location of said mobile devicecomprises using at least data acquired from global positioningsatellites (GPS) to determine said location.
 5. The method of claim 1,further comprising said host device receiving a request from saidapplication for said at least one item prior to said at least one itembeing placed in said one of said plurality of shopping carts; saidrequest being provided to said at least one shopping cart, wherein saidfirst display device is used to display a location of said at least oneitem within a store operated by said second party.
 6. The method ofclaim 5, wherein said location of said at least one item within saidstore is displayed along with a location of said first party in saidstore.
 7. The method of claim 6, wherein said location of said firstparty is determined by determining a location of said mobile devicewithin said store, said location of said mobile device being provided tosaid one of said plurality of shopping carts by said host device.
 8. Themethod of claim 6, wherein said location of said first party isdetermined by determining a location of said one of said plurality ofshopping carts within said store.
 9. The method of claim 1, wherein saidfirst display device is used to display third information to said firstparty, said third information being personalized for said first partyand based on data received from said host device, said data comprisingat least one of an item previously purchased by said first party and anitem on said first party's shopping list.
 10. A system for using atleast location information to facilitate a transaction between a firstparty and a second party, said transaction involving said first partypurchasing at least one item from said second party, comprising: amobile device in communication with a host device via a wide areanetwork (WAN) and comprising at least one memory device for storing anapplication adapted to perform the steps of: receiving login informationfrom said first party, said login information being used to identify anaccount for said first party, said account being linked to at least onepayment method; determining a location of said mobile device, saidlocation being provided to said host device via said WAN and used toidentify said second party; receiving data from said host device on saidat least one item after said at least one item has been placed in ashopping cart operated by said first party in a store operated by saidsecond party; displaying information to said first party via a displaydevice on said mobile device, said information including at least anamount due for said at least one item, said information being receivedfrom said host device via said WAN; and receiving an acknowledgementthat said first party would like to purchase said at least one item,said acknowledgement being provided to said host device via said WAN andresulting in said payment method being used to purchase said at leastone item from said second party; wherein said host device is configuredto use information received from said application to link at least oneof said first party, said application, and said mobile device to saidshopping cart; wherein said shopping cart is used to display data onsaid at least one item to said first party and to provide said data tosaid host device in response to said at least one item being placed insaid shopping cart.
 11. The system of claim 10, wherein said location ofsaid mobile device is acquired using at least global positioningsatellites (GPS).
 12. The system of claim 10, further comprising atleast one store device in communication with said host device via saidWAN and said shopping cart via at least one wireless communicationchannel, said shopping cart communicating with said host device via saidstored device.
 13. The system of claim 10, wherein said application isfurther adapted to receive a request from said first party for said atleast one item prior to said at least one item being placed in saidshopping cart, wherein said request is provided to said shopping cartvia said host device, said shopping cart being configured to display alocation of said at least one item within a store operated by saidsecond party.
 14. The system of claim 13, wherein said shopping cart isfurther configured to display a location of said first party in saidstore.
 15. The system of claim 14, wherein said location of said firstparty is determined by determining a location of said mobile devicewithin said store, said location of said mobile device being provided tosaid shopping cart via said host device.
 16. The system of claim 14,wherein said location of said first party is determined by determining alocation of said shopping cart within said store.
 17. The system ofclaim 16, wherein said shopping cart is configured to use locationinformation to determine its location within the store, where differentlocation information is transmitted from different locations within thestore.
 18. The system of claim 16, wherein said shopping cart isconfigured to use triangulation to determine its location within thestore.
 19. The system of claim 10, wherein said shopping cart is furtherused to display personalized information to said first party, saidpersonalized information being based upon data received from said hostdevice comprising at least one of an item previously purchased from saidstore and an item from said first party's shopping list.
 20. A methodfor purchasing an item from a second party, comprising: receiving logininformation for an application operating on a mobile device, said logininformation being used to identify an account linked to at least onepayment method; determining a location of said mobile device, saidlocation being provided to said host device via said wide area network(WAN) and used to identify a store operated by said second party; usingby said host device information received from said application to linksaid application to a shopping cart at said store; and displaying firstinformation on said shopping cart, said first information including atleast information on said item after said item has been placed in saidshopping cart, wherein data concerning said at least one item isprovided to said host device from said shopping cart via a store device,said shopping cart communicating with said store device via a wirelesscommunication channel and said store device communicating with said hostdevice via said WAN; displaying second information on said mobiledevice, said second information including at least an amount due forsaid item, said second information being received from said host devicevia said WAN; and receiving by said application an acknowledgement topurchase said item form said second party, said acknowledgementresulting in said payment method being used purchase said item.